Secure Sockets Layer (SSL)/Transport Layer Security (TLS) is primarily used to encrypt confidential data sent over an insecure network, such as the Internet. In the HTTPS protocol, the types of data encrypted include the URL, the HTTP header, cookies, and data submitted through forms. A Web page secured with SSL/TLS has a URL that begins with “https://”. The SSL/TLS security protocol is layered between the application protocol layer and TCP/IP layer, where it can secure and then send application data to the transport layer.
A SSL/TLS handshake protocol comprising a series of sequenced messages is used to negotiate the security parameters of a data transfer session. The SSL/TLS handshake begins with an initial Client Hello message that is sent to the web server. The Client Hello message contains a version number, randomly generated data, a session identification, a list of cipher suites available on the client, and a requested compression algorithm. Server Name Indication (SNI) is provided by TLS extensions, which allow clients to provide the name of the server they are contacting in the Client Hello message. The hostname contains the fully qualified DNS hostname of the server. This functionality is desirable, for example, to facilitate secure connections to servers that host multiple virtual servers at a single underlying network address.
The server responds to the Client Hello message with a Server Hello message. The Server Hello message includes a version number, randomly generated data, a session identification, a new or resumed session ID. If the client did not indicate a session to resume, then a new ID is generated. A new session ID is also generated when the client indicates a session to resume but the server can't or won't resume that session. This latter case also results in a new session ID, a cipher suite supported by both the client and server, and a compression algorithm. Specifies the compression algorithm to use (none currently supported).
The server also sends its SSL certificate to the client, which contains the server's public key that can be used to authenticate the server and to encrypt the premaster secret. The client checks the name of the server in the certificate to verify that it matches the name the client used to connect. If the user entered www.contoso.com as the URL in the browser, the certificate contains a subject name of www.contoso.com or *.contoso.com. The browser will warn the user if these names do not match, indicating that the server should not be trusted. In addition to being able to encrypt the data, SSL/TLS also ensures that the client is indeed communicating to the server that it has intended by ensuring that the domain name in the URL matches the subject name of the certificate that has returned from the server.
The server then sends a Server Hello Done message indicating that the server is finished and awaiting a response from the client. Additional messages are used for key exchanges and to verify and complete the SSL/TLS handshake.
Typically, with an exception of a wildcard SSL certificate or a SSL certificate with multiple subject names, a SSL certificate is issued for a specific site with matching subject for the domain name of the site. This creates problems of scale because each website needs its own SSL certificate. Accordingly, if there are million secure websites, then a million SSL certificates are needed. It can be a daunting problem for server administrators who are responsible for multiple websites to manage the SSL certificates for every website. Management of the SSL certificates can be especially difficult for administrators who support high-density hosting or cloud services. Additionally, because the SSL certificates expire annually, the on-going maintenance of the SSL certificates and the management of the one-to-one certificate/website associations is an on-going and time-consuming task.
The server admin must manage certificates for all of the websites on the server. Traditionally, when a client connects to a server over SSL/TLS, it can only identify the network end-point with IP:Port. Accordingly, in addition to managing certificates for all of the host websites, the admin must create a corresponding IP address for each website because each site wishes to maintain the standard SSL port, 443. This creates a scale problem for admins that host millions of web sites and, therefore, must manage millions of certificates and IP addresses.
SNI, by extending TLS, can now send the domain name, which is sometimes called virtual domain name, with the SSL Hello. With the domain name, the network end-point can now be uniquely identified using all three pieces of information, IP address, port and the domain name. This removes the need for the admin to create the million IP addresses since the same IP address and the port can remain constant, while the million unique domain names can be used to differentiate the web sites. However, the admin still has to create and manage the million certificates and must manage the one-to-one association between the million sites and the million certificates.
Using SNI, the SSL certificate corresponding to the site may be implied using a naming contract. For example, the SSL handshake from a SNI-capable client indicates that it is trying to connect to a particular domain name. In one such system, a naming contract dictates that the SSL certificate must be named <virtual domain name>.pfx. For example, for a domain such as www.contoso.com, the web service may use “www.contoso.com.pfx” as the name of the SSL certificate corresponding to the site. A system using this “.pfx” naming convention is described in pending U.S. patent application Ser. No. 13/069,032, titled “Central and Implicit Certificate Management” and filed Mar. 22, 2011, the disclosure of which is hereby incorporated by reference herein in its entirety.
Although such a naming convention eliminates the need to maintain the time-consuming, explicit one-to-one mapping, it has a hard dependency on the availability of the domain name at the time of SSL Client Hello, which is offered only by SNI-capable clients. The adoption of SNI across all clients is approximately 65%-75% as of September 2011, which leaves 25%-35% of all clients not SNI-capable. As a result, the naming convention that has a hard dependency on SNI alone is not ready for general consumption.